Using a Distributed Ledger for Tracking Vehicle Financial Events

ABSTRACT

Systems and methods are disclosed for interacting with a blockchain that stores financial data. The systems and methods may include (1) receiving, by one or more processors financial data from one or more remote computing devices; (2) detecting, by the one or more processors, a financial event for the vehicle from analysis of the financial data; (3) identifying, by the one or more processors, the VIN of the vehicle when the financial event for the vehicle is detected; (4) generating, by the one or more processors, a transaction (i) including the vehicle&#39;s VIN, (ii) describing the financial event for the vehicle, and (iii) detailing a current status, owner, and location of the vehicle; and/or (5) transmitting, from one or more processors to a server, the transaction to facilitate maintaining a VIN-based distributed ledger detailing financial events for the particular vehicle.

CROSS REFERENCE TO RELATED APPLICATIONS

This application claims priority to (1) U.S. Provisional Application No.62/466,917, entitled “Blockchain VIN Registry,” filed Mar. 3, 2017; (2)U.S. Provisional Application No. 62/468,092, entitled “Blockchain VINRegistry,” filed Mar. 7, 2017; (3) U.S. Provisional Application No.62/469,070, entitled “Using a Blockchain for Vehicle LifecycleProcesses,” filed Mar. 9, 2017; (4) U.S. Provisional Application No.62/500,977, entitled “Using a Blockchain for Vehicle LifecycleProcesses,” filed May 3, 2017; (5) U.S. Provisional Application No.62/501,621, entitled “Using a Blockchain for Vehicle LifecycleProcesses,” filed May 4, 2017; (6) U.S. Provisional Application No.62/550,131, entitled “Maintaining a Distributed Ledger for VINRecordkeeping,” filed Aug. 25, 2017; (7) U.S. Provisional ApplicationNo. 62/550,140, entitled “Using a Distributed Ledger for Total LossManagement,” filed Aug. 25, 2017; (8) U.S. Provisional Application No.62/550,172, entitled “Using a Distributed Ledger for Tracking VINRecordkeeping,” filed Aug. 25, 2017; (9) U.S. Provisional ApplicationNo. 62/550,186, entitled “Smart Contracts for Vehicle Events,” filedAug. 25, 2017; (10) U.S. Provisional Application No. 62/550,197,entitled Using a Distributed Ledger for Tracking Vehicle FinancialEvents,” filed Aug. 25, 2017; (11) U.S. Provisional Application No.62/550,224, entitled “Using a Distributed Ledger for the Auto ClaimsProcess,” filed Aug. 25, 2017; (12) U.S. Provisional Application No.62/550,245, entitled “Using a Distributed Ledger to Track a VINLifecycle,” filed Aug. 25, 2017; (13) U.S. Provisional Application No.62/550,261, entitled “Using a Distributed Ledger for Proof ofInsurance,” filed Aug. 25, 2017; (14) U.S. Provisional Application No.62/557,359, entitled “Systems and Methods for Updating a Loss HistoryBlockchain,” filed Sep. 12, 2017; (15) U.S. Provisional Application No.62/557,393, entitled “Systems and Methods for Analyzing Vehicle SensorData Via a Blockchain,” filed Sep. 12, 2017; (16) U.S. ProvisionalApplication No. 62/557,403, entitled “Systems and Methods for Utilizinga Blockchain for Maintaining Vehicle Collision Loss History,” filed Sep.12, 2017; (17) U.S. Provisional Application No. 62/557,415, entitled“Systems and Methods for Utilizing a Blockchain for Maintaining InsuredLoss History,” filed Sep. 12, 2017; (18) U.S. Provisional ApplicationNo. 62/557,433, entitled “Systems and Methods for Claim Processing ViaBlockchain,” filed Sep. 12, 2017; and (19) U.S. Provisional ApplicationNo. 62/557,446, entitled “Systems and Methods for Updating an InsuredLoss History Blockchain,” filed Sep. 12, 2017, each of which is herebyincorporated herein by reference in its entirety.

TECHNICAL FIELD

The present disclosure generally relates to the maintenance of adistributed ledger that governs autonomous, smart, or other vehicletransactions or events, and/or related smart contracts, and moreparticularly, using a distributed ledger to track vehicle financialevents.

BACKGROUND

Conventional techniques associated with tracking and maintainingvehicles have limitations associated with tracking each vehicle'scurrent location, current owner, and/or current condition. Conventionaltechniques may also have other drawbacks.

BRIEF SUMMARY

In one aspect, a computer-implemented method for creating and/ormaintaining a VIN-based distributed ledger of financial transactions orevents pertaining to a particular vehicle may be provided. The methodmay include: (1) receiving, by one or more processors and/ortransceivers, vehicle or financial data from one or more remotecomputing devices (e.g. user mobile devices, connected vehicles, vehiclesensors, vehicle manufacturer remote servers, bank remote servers,insurance provider remote servers, or repair facility remote servers),such as via wireless communication or data transmission over one or moreradio frequency links or digital communication channels; (2) detecting,by the one or more processors, a financial event for the vehicle fromanalysis of the vehicle or financial data; (3) identifying, by the oneor more processors, the VIN of the vehicle or retrieving the VIN from amemory unit or the vehicle (or the vehicle's processor or memory) whenthe financial event for the vehicle is detected; (4) generating, by theone or more processors, a transaction or event (i) including thevehicle's VIN, (ii) describing the financial event for the vehicle,and/or (iii) detailing a current status, owner, and/or location of thevehicle; and/or (5) transmitting, from one or more processors and/ortransceivers to a server (such as via wireless communication or datatransmission over one or more radio frequency links), the transaction tofacilitate creating and/or maintaining a VIN-based distributed ledgerdetailing financial events for the particular vehicle. The method mayinclude additional, less, or alternate functionality, including thatdiscussed elsewhere herein.

In another aspect, a computer-implemented method for maintaining aVIN-based distributed ledger of financial transactions or eventspertaining to a particular vehicle may be provided. The method mayinclude (1) receiving, by one or more processors financial data from oneor more remote computing devices; (2) detecting, by the one or moreprocessors, a financial event for the vehicle from analysis of thefinancial data; (3) identifying, by the one or more processors, the VINof the vehicle when the financial event for the vehicle is detected; (4)generating, by the one or more processors, a transaction (i) includingthe vehicle's VIN, (ii) describing the financial event for the vehicle,and/or (iii) detailing a current status, owner, and location of thevehicle; (5) updating, by the one or more processors, a smart contractassociated with the vehicle; and/or (6) transmitting, from one or moreprocessors to a server, the transaction to facilitate maintaining aVIN-based distributed ledger detailing financial events for theparticular vehicle. The method may include additional, less, oralternate functionality, including that discussed elsewhere herein.

In yet another aspect, a computer system configured for creating and/ormaintaining a VIN-based distributed ledger of financial transactions orevents pertaining to a particular vehicle may be provided. The computersystem may include one or more processors, transceivers, sensors, and/orservers configured to: (1) receive vehicle or financial data from one ormore remote computing devices (e.g. user mobile devices, connectedvehicles, vehicle sensors, vehicle manufacturer remote servers, bankremote servers, insurance provider remote servers, or repair facilityremote servers), such as via wireless communication or data transmissionover one or more radio frequency links or digital communicationchannels; (2) detect a financial event for the vehicle from analysis ofthe vehicle or financial data; (3) identify the VIN of the vehicle orretrieving the VIN from a memory unit or the vehicle (or the vehicle'sprocessor or memory) when the financial event for the vehicle isdetected; (4) generate a transaction or event (i) including thevehicle's VIN, (ii) describing the financial event for the vehicle,and/or (iii) detailing a current status, owner, and/or location of thevehicle; and/or (5) transmit to a server (such as via wirelesscommunication or data transmission over one or more radio frequencylinks), the transaction or event to facilitate creating and/ormaintaining a VIN-based distributed ledger detailing financial eventsfor the particular vehicle. The system may include additional, less, oralternate functionality, including that discussed elsewhere herein.

The method may be implemented via computer systems, and may includeadditional, less, or alternate actions or functionality. Systems orcomputer-readable media storing instructions for implementing all orpart of the method described above may also be provided in some aspects.Systems for implementing such methods may include one or more of thefollowing: a special-purpose computing device, a personal electronicdevice, a processing unit of a vehicle, a remote server, one or moresensors, one or more communication modules configured to communicatewirelessly via radio links, radio frequency links, and/or wirelesscommunication channels, and/or one or more program memories coupled toone or more processors of the personal electronic device, processingunit of the vehicle, or remote server. Such program memories may storeinstructions to cause the one or more processors to implement part orall of the method described above. Additional or alternative featuresdescribed herein below may be included in some aspects.

Advantages will become more apparent to those of ordinary skill in theart from the following description of the preferred aspects, which havebeen shown and described by way of illustration. As will be realized,the present aspects may be capable of other and different aspects, andtheir details are capable of modification in various respects.Accordingly, the drawings and description are to be regarded asillustrative in nature and not as restrictive.

BRIEF DESCRIPTION OF THE DRAWINGS

The figures described below depict various aspects of the system andmethods disclosed herein. It should be understood that each figuredepicts an embodiment of a particular aspect of the disclosed system andmethods, and that each of the figures is intended to accord with apossible embodiment thereof. Further, wherever possible, the followingdescription refers to the reference numerals included in the followingfigures, in which features depicted in multiple figures are designatedwith consistent reference numerals.

There are shown in the drawings arrangements which are presentlydiscussed, it being understood, however, that the present embodimentsare not limited to the precise arrangements and instrumentalities shown,wherein:

FIG. 1A depicts an exemplary computing environment including componentsand entities associated with creating, maintaining and utilizing adistributed ledger or Blockchain VIN Registry;

FIG. 1B depicts another exemplary computing environment includingcomponents and entities associated with creating, maintaining andutilizing a distributed ledger or Blockchain VIN Registry, in accordancewith some embodiments;

FIG. 2 depicts an exemplary VIN Chain, which may be associated withcompiling transactions into blocks of the distributed ledger orBlockchain VIN Registry, in accordance with some embodiments;

FIG. 3 depicts several exemplary VIN-based vehicle services;

FIG. 4 depicts an exemplary virtual claim experience that includesvarious tasks and outputs that may be accomplished, at least in part,via the Blockchain VIN Registry; and

FIG. 5 depicts an exemplary computer-implemented method 500 for using adistributed ledger for tracking vehicle financial events.

The figures depict aspects of the present embodiments for purposes ofillustration only. One skilled in the art will readily recognize fromthe following discussion that alternate aspects of the structures andmethods illustrated herein may be employed without departing from theprinciples of the invention described herein.

DETAILED DESCRIPTION

The present embodiments may relate to, inter alia, creating and/ormaintaining a distributed ledger related to Vehicle IdentificationNumbers (VINs), i.e., a Blockchain VIN Registry. In some aspects, theBlockchain VIN Registry may be used to maintain vehicle informationup-to-date (vehicle location, vehicle owner, vehicle condition, vehiclemileage, vehicle usage, etc.) and/or carry out smart contractsassociated with individual vehicles. Each block or update to theBlockchain VIN Registry may include the vehicle's VIN number or use thevehicle's VIN number, or a hash or encrypted version thereof, as a keyto access and/or update the Blockchain VIN Registry. Each block orupdate may also include one or more additional data elements associatedwith the vehicle or vehicle transactions/events, including those dataelements discussed elsewhere herein.

A national or other registry of automobile VIN numbers may be commonlyaccessed and/or updated by organizations, such as auto manufacturers,insurance carriers, financial institutions, fleet owners, banks, bodyshops, part suppliers, State Departments of Motor Vehicles (DMVs),and/or salvage vendors. The VIN Registry, utilizing blockchaintechnology, may be a single, historical, authoritative source formultiple pieces of information about each vehicle that is accessed,tracked, and updated using Vehicle Identification Numbers (VINs).

The Blockchain VIN Registry may have various usages, and may allow forthe introduction of new capabilities into current processes. Examples ofsuch usage include: (1) validating proof of insurance on a vehicle(available to law enforcement, lienholders, vehicle owners, etc.); (2)tracking vehicle ownership from “cradle to grave”, via seamless titletransfers between manufacturers, dealers, consumers, salvage yard, etc.;(3) identifying the current lienholder of a vehicle, and the currentlien payoff amount (e.g., for more frictionless processing of paymentsuch as in a total loss situation, or for loan refinancing situations);(4) ensuring lien perfection (e.g., title reflects joint ownership byperson and lienholder); (5) reducing fraud by detecting duplicatecoverage or duplicate claims for a single vehicle, or detecting buildupor questionable claims; (6) tracking maintenance or repair work that hasbeen, or is to be, performed on a vehicle; (7) when coupled with crashdetection, performing first notification of loss to the appropriateinsurer; (8) in conjunction with connected car capabilities, limitingthe vehicle's capabilities if the vehicle isn't registered properly,lacks insurance coverage, or the owner is behind on loan payments; (9)connected license plates, reflecting the current registration status;(10) facilitating Usage-Based Insurance (UBI) or trip-based insurance;(11) recording all OEM features, part numbers, (autonomous or othervehicle) system or software of versions of the vehicle (beyond what canbe derived from the VIN, make, and model information), i.e., the vehiclebuild; (12) more accurate insurance rating based upon known security orsafety features of a vehicle (which may impact either a human drivenvehicle, or a semi-autonomous or autonomous vehicle or technology, orboth); (13) more accurate repair cost estimations based upon knownvehicle features (which may impact human driving, or vehicleself-driving); and/or (14) facilitating recall notifications in a promptand reliable manner.

Potential blockchain participants may include auto manufacturers,insurance carriers, consumers, individual vehicle owners, fleet owners,salvage vendors, auditors, State DMVs, auto dealerships, banks or creditunions, lienholders, body shops, repair facilities, tow truckoperations, part supplies, rental companies, and/or law enforcement.

Potential data elements included in the blockchain and/or eachblockchain transaction, block, or update may include vehicle VIN number,and one or more additional data elements associated with that particularvehicle. The additional data elements may include owner information,such as owner type (manufacturer, dealer, consumer, lienholder, etc.);owner ID (EIN, SSN, etc.); owner name; and/or owner contact information(address, phone, email address, etc.). The additional data elements mayinclude insurance carrier information, such as insurer name; insurancepolicy ID or number; an indication of whether the policy remains inforce (Y/N?); effective dates of the policy; expiration date of theinsurance coverage; and/or insurance policy coverages, terms, limits,deductibles, conditions, etc.

The additional data elements may include lienholder information, such aslienholder name; lienholder contact information; whether the loan is ingood standing (Y/N?); and/or current payoff amount. The additional dataelements may include a license plate number; state of issuance; andwhether the vehicle registration with the state DMV is up-to-date. Theadditional data elements may include an indication of any claims made;including date of first notice of loss; insurance carrier that the claimwas filed with; claim open date; claim close date; an amount of theclaim; and whether or not the claim was resolved. The additional dataelements may include information on maintenance or repair events,including event type; event date; event cost; and/or one or morelocations associated with the event (e.g., city and state of eventlocation).

The Blockchain VIN Registry may be used in conjunction with smartcontracts that govern the vehicles, including autonomous orsemi-autonomous vehicles. For instance, the smart contracts may relatedto maintenance, warranties, vehicle loans, service contracts, UBI,trip-insurance, auto insurance policies, vehicle titles, vehiclesalvage, total loss vehicles, etc. When an event or data relevant to avehicle or a smart contract is generated, a transaction associated withthe vehicle's VIN may be generated and compiled into a block of adistributed ledger (or Blockchain VIN Registry). The transaction orupdate to the distributed ledger or Blockchain VIN Registry may include(i) the vehicle's VIN, and (ii) one or more additional data elementsassociated with the vehicle, including the additional data elementsmentioned elsewhere herein.

Some embodiments may also relate to autonomous vehicle operationmonitoring and/or assessment. The operation of the autonomous vehiclesmay impact the obligations of various parties associated with theautonomous vehicle, for example, an operator of the autonomous vehicle,a manufacturer of the autonomous vehicle, an insurer of the operator, aninsurer of the autonomous vehicle, and/or other parties. To this end,the present embodiments may leverage the use of a distributed ledgerand/or smart contracts to codify and/or automatically enforce theseobligations.

A distributed ledger is a transactional record that is maintained ateach node of a peer to peer (P2P) network. Commonly, the distributedledger is comprised of groupings of transactions bundled together into a“block.” When a change to the distributed ledger is made (e.g., when anew transaction and/or block is created), each node must form aconsensus as to how the change is integrated into the distributedledger. Upon consensus, the agreed upon change is pushed out to eachnode so that each node maintains an identical copy of the updateddistributed ledger. Any change that does not achieve a consensus isignored. Accordingly, unlike a traditional, centralized ledger, a singleparty cannot unilaterally alter the distributed ledger.

In one application of distributed ledgers, each new block may becryptographically linked to the previous block in order to form a“blockchain.” More particularly, to create a new block, each transactionwithin a block may be assigned a hash value (i.e., an output of acryptographic hash function, such as SHA-2 or MD5). These hash valuesmay then be combined together utilizing cryptographic techniques (e.g.,a Merkle Tree) to generate a hash value representative of the entire newblock. This hash value may then be combined with the hash value of theprevious block to form a hash value included in the header of the newblock, thereby cryptographically linking the new block to theblockchain. To this end, the precise value utilized in the header of thenew block is dependent on the hash value for each transaction in the newblock, as well as the hash value for each transaction in every priorblock.

According to some aspects, the hash value generated for the new blockmay be used as an input to a cryptographic puzzle that manipulates anonce value. When a solution to the cryptographic puzzle is found, thesolving node publishes the solution and the other nodes then verify thatthe solution is the correct solution. Because the solution may alsodepend on the particular hash values for each transaction within theblockchain, if the solving node attempted to modify any transaction, thesolution would not be verified by the other nodes. More particularly, ifa single node attempts to modify a prior transaction within theblockchain, a cascade of different hash values are generated for eachtier of the cryptographic combination technique. This results in theheader for one or more blocks being different than the correspondingheader(s) in every other node that did not make the exact samemodification. As a result, the solution generated by the modifying nodewould not solve the cryptographic puzzle presented to any node withoutthe identical modification. Thus, the version of the new block generatedby the modifying node is readily recognized as including an impropermodification and is rejected by the consensus. This inability to modifypast transactions lead to blockchains being generally described astrusted, secure, and/or immutable.

A smart contract is a computer protocol that enables the automaticexecution and/or enforcement of an agreement between different parties.In particular, the smart contract may be computer code that is locatedat a particular address on the blockchain. In some cases the smartcontract may run automatically in response to a participant in theblockchain sending funds (e.g., a cryptocurrency such as bitcoin orether) to the address where the smart contract is stored. Additionally,smart contracts may maintain a balance of the amount of funds that arestored at their address. In some scenarios, when this balance reacheszero, the smart contract may no longer be operational.

The smart contract may include one or more trigger conditions, that,when satisfied, correspond to one or more actions. For some smartcontracts, which action(s) from the one or more actions are performed isdetermined based upon one or more decision conditions. An enforcemententity corresponding to the smart contract may subscribe to one or moredata streams including data related to a trigger condition and/or adecision condition. Accordingly, the enforcement entity may route thedata streams to the smart contract (such as by using the vehicle's VIN)so that the smart contract may detect that a trigger condition hasoccurred and/or analyze a decision condition to direct the enforcemententity to perform one or more actions.

As an example, a pay-per-trip insurer may include a maximum distance theautonomous vehicle may traverse in each trip. In this example, a driverand the pay-per-trip insurer may generate a smart contract to insure aparticular trip. In response, the enforcement entity may receive anodometer data stream from the covered vehicle as identified by VIN. Ifthe autonomous vehicle incurs liability during the trip (e.g., a triggerevent occurred), the smart contract may automatically analyze theodometer data feed, which may include the VIN, to determine whether theautonomous vehicle was operated within the bounds of the maximumdistance in the insurance agreement (e.g., a decision condition).Accordingly, the smart contract may direct the performance of an actionto automatically assign liability to an operator, autonomous vehicle, orthe insurer based upon the odometer data feed. Of course, sensorsmonitoring an autonomous vehicle may be leveraged to facilitate manyother types of transactions associated with a vehicle and/or a smartcontract.

Given the relative ease to modify computer files, including a smartcontract computer file, and the parties' competing incentives, thereneeds to be a system that all parties trust to fairly and accuratelyregulate and enforce the smart contract. For at least the above reasons,a distributed ledger and/or a blockchain system, in this case aBlockchain VIN Registry may be utilized to establish such a trustedsystem.

To this end, the distributed ledger may be leveraged to record the smartcontract and/or the vehicle or other data related to the triggerconditions and/or decision conditions of the smart contract. Moreparticularly, the data, including vehicle sensor data or mobile devicesensor data, utilized to determine the presence of a trigger conditionand/or to analyze decision conditions to determine an action (such as aVIN-related action or condition) may be recorded within a transactionincluded in the distributed ledger. By recording this data in thedistributed ledger, there is a public and trusted record of the smartcontract and the reasoning behind any action performed as directed bythe smart contract. As a result, the parties that generated the smartcontract may automatically enforce their contracts in a transparent andobjective manner. For at least this reason, an entity the regularlygenerates smart contracts, such as an insurer, may establish adistributed ledger to govern and enforce or maintain a plurality of itssmart contracts. According to certain aspects, the distributed ledgermay either be a public ledger (each node may readily view the underlyingdata of each transaction) or a private ledger (the underlying data needsan encryption key to be viewed), or a combination of public and privateledger aspects.

According to certain aspects, an electronic device associated with eachvehicle may execute an application to monitor vehicle data that isrelevant to the enforcement of a smart contract—such as vehicleoperational data, vehicle telematics data, vehicle sensor data, vehiclecondition data, mileage data, maintenance data, parts data, system data,system or software version data, mobile device data, GPS data, etc. Theapplication may interpret the vehicle data to generate a “transaction”or a time-stamped record of the relevant vehicle data. In oneembodiment, the transaction may include the VIN of an autonomous orother vehicle, a time of the transaction, and an indication of one ormore vehicle conditions or events relevant to a smart contract.

In one embodiment, the application may process vehicle data or vehicleoperational data to create the indication of the vehicle condition. Forexample, the application may process an airbag activation event todetermine that the autonomous vehicle was involved in a collision. As aresult, the application may generate a transaction that indicates aliability-inducing event occurred. The transaction may further includedata relating to one or more decision conditions that the smart contractanalyzes to determine an action to perform in response to the triggercondition.

Exemplary Environments for Creating & Maintaining Distributed Ledger orBlockchain VIN Registry

FIG. 1A depicts an exemplary environment 100 for creating and/ormaintaining a distributed ledged or Blockchain VIN Registry. AlthoughFIG. 1 depicts certain entities, components, and devices, it should beappreciated that additional or alternate entities and components areenvisioned.

As illustrated in FIG. 1A, the environment 100 may include a pluralityof autonomous, smart, or other vehicles 105 a-f. As it is generally usedherein, the term “autonomous vehicle” refers to any vehicle withautonomous (or even semi-autonomous) capabilities. Thus, “autonomousvehicle” is not limited to fully autonomous vehicles (SAE level 5) andincludes even partially automated vehicles (SAE level 2). It should beappreciated that in fully autonomous vehicles, an “operator” may includea person that provides navigational input to the autonomous vehicleand/or a person located within the vehicle at a location wherein theperson is capable of engaging manual control should the need and/ordesire arise.

As illustrated on the autonomous or smart vehicle 105 a, the autonomousor smart vehicle 105 a may include one or more sensors 101 a-b thatmonitor the operational status of the autonomous or smart vehicle 105 a.The sensors 101 may include, for example, a pressure sensor, agyroscope, an accelerometer, an odometer, a vibration sensor, amicrophone, an image sensor, a temperature sensor, and/or a radar orLIDAR sensor. Some of the sensors 101 may be included in the autonomousor smart vehicle 105 a by a manufacturer of the vehicle 105 a and othersof the sensors 101 may be retrofitted onto the vehicle 105 a at somepoint after manufacture. For example, a fleet manager may retrofit thevehicle 105 a with a particular type of sensor that relates to a smartcontact frequently generated by the fleet manager.

The autonomous or smart vehicle 105 a may further include an electronicdevice 103 configured to interpret operational or vehicle data generatedby the sensors 101. Although FIG. 1A illustrates the electronic device103 as a processing unit of the vehicle 105 a interconnected to thesensors 101 via a communication bus of the vehicle 105 a, in otherembodiments the electronic device 103 may be a personal electronicdevice (e.g., a mobile phone, a tablet, a laptop computer, a smartwatch, smart glasses, other types of wearable electronics, an on-boarddiagnostic monitor, and so on) associated with an operator of thevehicle 105 a. In these embodiments, the personal electronic device mayreceive the operational or vehicle data via a wireless interface (e.g.,a Bluetooth interface, a Wi-Fi interface, or other known wirelesscommunication interfaces) or a wired interface (e.g., an OBD port, a USBinterface, an auxiliary interface, or other known wired communicationinterfaces). Additional information describing the operation ofautonomous vehicles may be found in co-owned U.S. patent applicationSer. No. 14/713,249, entitled “AUTONOMOUS VEHICLE OPERATION FEATUREMONITORING AND EVALUATION OF EFFECTIVENESS,” the entire disclosure ofwhich is hereby incorporated by reference.

Regardless of the particular type of electronic device, the electronicdevice 103 may include an application configured to analyze theoperational data generated by the sensors 101. More particularly, theapplication may be configured to analyze the operational or vehicle datato detect a plurality of conditions (e.g., trigger conditions ordecision conditions) associated with the vehicle 105 a. Periodicallyand/or in response to a change in condition, the application maygenerate a transaction that incorporates one or more of the detectedconditions, as well as the vehicle VIN.

According to certain aspects, the transaction may include indications ofthe one or more conditions, a VIN of the vehicle 105 a and/or theoperator of the vehicle 105 a, a timestamp, an indication of a priority,one or more additional data elements as discussed elsewhere (see, e.g.,FIG. 2 and discussion thereof), and/or a portion of the operational orvehicle data upon which the one or more detected conditions may bebased. The electronic device 103 may transmit generated transactions viaan antenna 104. Although FIG. 1 illustrates the antenna 104 as beingseparate from the electronic device 103, it should be appreciated thatfor some types of electronic devices, such as a mobile phone, theantenna 104 may be included in the electronic device 103 itself.

The plurality of autonomous, smart, or other vehicles 105 a-f may beconfigured to communicate with an enforcement server 115 via one or morecommunication networks 110, for example, via wireless communication ordata transmission over one or more radio links or digital communicationchannels. The enforce server 115 may also communicate with 3^(rd) partyremote servers or 3^(rd) party applications 125 via one or morecommunication networks 110, for example, via wireless communication ordata transmission over one or more radio links or digital communicationchannels. The 3^(rd) party remote servers may relate to DMVs, vehicledealership, insurance provider, financial services providers, partsuppliers, vehicle repair facility or body shop, rental company, salvagevendor, and/or other 3^(rd) party remote servers or computing devices,including those discussed elsewhere herein.

The networks 110 may facilitate any data communication between theplurality of autonomous vehicles 105 a-f and/or 3^(rd) party remoteservers, and an enforcement server 115 via any standard or technology(e.g., GSM, CDMA, TDMA, WCDMA, LTE, EDGE, OFDM, GPRS, EV-DO, UWB, IEEE802 including Ethernet, WiMAX, and/or others). According to the presentembodiments, the plurality of autonomous, smart, or other vehicles 105a-f and/or 3^(rd) party remote servers may transmit generatedtransactions to the enforcement server 115 via the networks 110. In someembodiments, the networks 110 may include a mesh or ad hoc networkwherein a portion of the plurality of vehicles 105 a-f or 3^(rd) partiesfunction as nodes of the mesh or ad hoc network. Thus, in someembodiments, a transaction generated at the vehicle 105 a or 3^(rd)party may be routed to, for example, the vehicle 105 c and the vehicle105 f or 3^(rd) party prior to the enforcement server 115.

It should be appreciated that standard or technology used to communicatebetween and among the plurality of vehicles 105 a-f and 3^(rd) partiesis not necessarily the same standard or technology utilized tocommunicate between one of the plurality of vehicles 105 a-f or 3^(rd)parties, and the enforcement server 115. In addition to the transaction,in some embodiments, one or more of the plurality of vehicles 105 or3^(rd) parties may exchange operational data over the mesh or ad hocnetwork in response to the one or more of the plurality of vehiclesbeing involved in a collision.

According to certain aspects, the enforcement server 115 may beconfigured to compile new blocks to add to a blockchain, such as byusing the vehicle VIN (e.g., the enforcement server may identify theblockchain to add new blocks to using the VIN, or otherwise use the VINto access the blockchain or update the blockchain), and to enforce aplurality of smart contracts. The smart contracts may relate to vehicletitle, vehicle ownership, vehicle title transfer, vehicle maintenance,vehicle insurance, vehicle repair work or parts, vehicle financing,vehicle build, etc.

Although FIG. 1A illustrates a single enforcement server 115, it shouldbe appreciated that in some embodiments, the enforcement server 115 maybe a plurality of interconnected servers, for example, in a cloudcomputing environment. In one aspect, the enforcement server 115 mayperiodically compile a plurality of transactions received from theplurality of autonomous vehicles 105 and/or 3^(rd) parties. Theenforcement server 115 may also periodically compile a plurality oftransactions received from the plurality of autonomous, smart, or othervehicles 105 and/or 3^(rd) parties in response to receiving an urgenttransaction.

After the new block is compiled, the enforcement server 115 may transmitthe new block to dedicated validation entities 135 to generate asolution to incorporate the block into blockchain and/or to form aconsensus on the solution. Although FIG. 1 illustrates that thededicated validation entities as being separate from the enforcementserver 115, it should be appreciated that the enforcement server 115 mayitself include a module dedicated to generating a solution to thecryptographic puzzle and/or forming a consensus on the solution.

In another aspect, the enforcement server 115 may analyze a smartcontract database (not depicted) to determine whether any transactionscompiled into the new block are associated with a smart contract, suchas by using the vehicle VIN or comparing a block VIN with a smartcontract VIN (e.g., each block in the block may use a VIN as anidentifier, and each smart contract may also use the VIN as anidentifier or as an access key). To this end, the enforcement server 115may extract from each transaction one or more indications identifying anautonomous, smart, or other vehicle (such as by VIN) and/or an operatorof the autonomous vehicle and route the transaction to a respectivelycorresponding one or more smart contracts that govern the VIN, or theidentified vehicle and/or operator. In one scenario, the transaction mayinclude, in addition the VIN, a plurality of vehicle-related, vehicleoperational, vehicle or mobile device sensor data; 3^(rd) party data ordata generated by a 3^(rd) party's computing devices or sensors; and/orother data relating to the status of a trigger condition and/or one ormore decision conditions.

In response, the particular smart contract may direct the enforcementserver 115 to perform an action to enforce the particular smartcontract. For example, the action may be to generate and/or file aninsurance claim, which may include a vehicle's VIN. Depending on theaction, the enforcement server 115 may execute one or more third partyapplications 125 (or vehicle applications) to carry out the action. Inthe insurance claim example, a third party insurer may include anapplication configured to generate and/or process the insurance claimbased upon data included in the transaction. As another example, anemergency response entity (e.g., an EMT) may include an application inthe third party applications 125 to dispatch a responder to a locationof an autonomous vehicle or other vehicle involved in a vehiclecollision.

In some scenarios, a decision condition requires the analysis of datanot generated at or by an autonomous, smart, or other vehicle. As anexample, a decision condition may be related to a weather condition atthe time liability occurred (e.g., the presence of rain when theliability was incurred). Accordingly, the smart contract may interactwith one or more third party applications 125 to retrieve thisadditional decision condition data, including information available fromthird parties or the internet. In this example, one of the third partyapplications 125 may be a weather service application capable ofoutputting weather conditions at the location of the vehicle at the timeindicated by the timestamp of the transaction. In one aspect, the smartcontract may modify the transaction to include the additional conditiondata (assuming the transaction has not been compiled into a block)and/or generate a new transaction that indicates the additionalcondition data. The exemplary environment 100 may include additional,fewer, or alternate equipment or components, including those discussedelsewhere herein. Further, in some embodiments, the actions described asbeing performed by the enforcement server 115 may additionally oralternatively be performed at one or more of the vehicles 105 a-f,and/or 3^(rd) party servers.

Turning now to FIG. 1B, depicted is another exemplary environment 150for creating and/or maintaining a distributed ledger or Blockchain VINRegistry. Although FIG. 1B depicts certain entities, components, anddevices, it should be appreciated that additional or alternate entitiesand components are envisioned.

As illustrated in FIG. 1B, the environment 150 may include a distributedledger or Blockchain VIN Registry 145. The distributed ledger orBlockchain VIN Registry 145 may be maintained via a network of nodes,including one or more autonomous, smart, or other vehicles 105, 3 ^(rd)party remote servers or other computing devices, and/or an enforcementserver 115. The nodes may have access distributed ledger 145 and/orgenerate data included in the distributed ledger 145. As describedabove, the distributed ledger 145 may not be changed without firstforming a consensus on the change. Accordingly, as depicted by FIG. 1B,the distributed ledger 145 may be considered separate from anyindividual node, even though the individual nodes may store local copiesof the distributed ledger 145.

According to certain aspects, as described with respect to FIG. 1A, theautonomous or smart vehicle 105 may include a plurality of sensors 101a-b, an electronic device 103, and/or an antenna 104. The autonomous orsmart vehicle 105 may communicate with 3^(rd) party remote servers,and/or the enforcement server 115 via the electronic device 103 and/orthe antenna 104.

As illustrated, the enforcement server 115 may include a blockchainmanager 117. The blockchain manager 117 may be a software program,engine, and/or a module that is executed by one or more processorsinterconnected with the enforcement server 115. In one embodiment, theblockchain manager 117 may compile a plurality of transactionsassociated with, or identified by, an individual or particular VIN intoa block, update the distributed ledger 145 to include a block, routetransaction data to one or more smart contracts using the VIN, and/orautomatically enforce one or more smart contracts associated with theVIN.

According to certain aspects, an operator of the enforcement server mayinteract with a management interface 119 to control aspects of thedistributed ledger 145 and/or set control parameters associated with theblockchain manager 117. For example, a period for which blocks aregenerated may be set via the management interface 119. In one aspect,the plurality of smart contracts associated with the distributed ledger145 and the VIN may be stored in a smart contracts database 130.Although FIG. 1B depicts the smart contract database 130 as a part ofthe enforcement sever 115, the smart contract database may be maintainedwithin the distributed ledger 145.

According to certain aspects, one or more public devices 123 may accessdata stored at the enforcement server via a public interface 121, suchas by using the vehicle's VIN to access the data. The public interface121 may be a read only interface that prevents the one or more publicdevices 123 from writing transactions to the distributed ledger 145. Tothis end, the one or more public devices 123 may be used, for example,to view data maintained within the distributed ledger 145 associatedwith a VIN, to view the status of one or more smart contracts associatedwith the VIN and/or the distributed ledger 145, compile statisticsregarding data maintained in the distributed ledger, and so on.

Additionally or alternatively, one or more 3^(rd) party applications 125may interact with the distributed ledger 145 via an API 127 of theenforcement server 115. The 3^(rd) party applications 125 may beassociated with one or more entities associated with an autonomousvehicle. For example, the 3^(rd) party applications 125 may include anapplication to generate various transactions identified by VIN, such asgenerate and/or file an insurance claim, send a repair request, send atow request, contact an emergency service provider, perform maintenance,pay auto claims, update telematics data, update insurance policies,update UBI or trip insurance, update title status, update ownershipinformation, update lien and lienholder information, and so on. Itshould be appreciated that although FIG. 1B depicts the 3^(rd) partyapplications 125 as separate from the enforcement sever 115, in someembodiments a portion of the 3^(rd) party applications 125 may be storedlocally at the enforcement server 115.

The exemplary environment 150 may include additional, fewer, oralternate equipment or components, including those discussed elsewhereherein. Further, in some embodiments, the actions described as beingperformed by the enforcement server 115 may additionally oralternatively be performed at one or more of the autonomous, smart, orother vehicles 105, or mobile devices, or 3^(rd) party remote servers orcomputing devices.

Exemplary VIN Chain or Blockchain VIN Registry

FIG. 2 depicts an exemplary VIN Chain 200. The VIN Chain may be aBlockchain VIN Registry as discussed herein. The VIN for a vehicle mayact a key, or other provides access, to the VIN Chain 200, and in someembodiments may be hashed or encrypted.

In some embodiments, each VIN Chain 200 may be a blockchain dedicated toan individual autonomous, smart, or other (conventional) vehicle. TheVIN Chain 200 may be required to include the VIN for the vehicle. TheVIN may be used to access, identify, or verify the VIN Chain 200 ordistributed ledger is associated with the vehicle. The VIN Chain 200 mayinclude one or more additional data elements associated with thevehicle, including those depicted in FIG. 2.

As shown in FIG. 2, the VIN Chain 200 or Blockchain VIN Registry mayhave a VIN number associated with a particular vehicle that acts as akey to accessing or updating the VIN Chain 200. The VIN Chain 200 mayhave several data elements, including (1) owner information, (2) titlestatus (clean, salvaged, etc.), (3) lienholder information, (4) lienpayoff amount, (5) insurance policy start and stop date, (6) insuranceclaim open and close date, (7) build data (vehicle features), (8)maintenance and repair dates and types, (9) telematics and odometerdata, and/or other data elements, including those discussed elsewhereherein.

For instance, the additional data elements may include telematics data(such as driving, braking, speed, cornering, stop/start, acceleration,etc.) associated with a particular driver or vehicle. The insurancepolicy information may include UBI or trip-based insurance details, suchas location and mileage information. The insurance policy informationmay also include premiums, discounts, coverages, deductibles, limits,and/or conditions.

As shown in FIG. 2, the owner information and title status blocks in theVIN Chain 200 may be created or updated, and subsequently accessed orread by manufacturers, dealerships, body shops, DMVs, insurers, salvagevendors, individual smart vehicles, vehicle owners, authorized 3^(rd)parties, and/or other entities. One use case for this type ofinformation in a blockchain is title tracking from “cradle to grave.”

The lienholder and lien amount information blocks in the VIN Chain 200may by created or updated by lienholders or vehicle owners, andsubsequently accessed by insurers, lienholders, and/or consumers. Usecases for this type of information in a blockchain may be the claimpayment for a total loss situation, and/or automobile refinancing.

The insurance policy start and end data, and claim open and close dateinformation blocks in the VIN Chain 200 may be created or updated byinsurers, smart vehicles, or consumers, and subsequently accessed orread by insurers, lienholders, other vehicles, and consumers. The usecases for this type of information in a blockchain may be providingevidence of insurance, detecting buildup or fraud, and/or alternativelyverifying the veracity of insurance claims.

The build data (such as vehicle features or technology) blocks in theVIN claim 200 may be created or updated by manufactures or individualsmart vehicles, and subsequently read by other vehicles, insurers,consumers, other manufacturers, repair shops, etc. Use cases for thistype of information in a blockchain may include insurance rating (e.g.,vehicles having different safety or technological systems that lower orotherwise impact risk may be rated different), and improved repair costestimates.

The maintenance and repair data blocks in the VIN claim 200 may becreated or updated, and subsequently read or accessed by body shops,repair facilities, insurers, individual smart or connected vehicles,etc. A use case for this type of information in a blockchain may includemaintaining the vehicle history.

The telematics and/or odometer data blocks in the VIN Chain 200 may becreated or updated by individual smart or connected vehicles, andsubsequently read by the vehicles, consumers, insurers, or other 3^(rd)parties. The telematics and/or odometer data may be used to update smartcontracts associated with UBI (Usage-Based Insurance), which may provideinsurance for a limited amount of miles or time. Use cases for this typeof information in a blockchain may include claim processing, updatinginsurance discounts, and/or issuing new or additional UBI smartcontracts.

Exemplary VIN Based Vehicle Services

FIG. 3 depicts exemplary VIN based vehicle services that may befacilitated via the Blockchain VIN Registry. The VIN based vehicleservices may relate to (1) State Department of Motor Vehicles (e.g.,vehicle registration, title management, title transfer, license plates,etc.); (2) Banking (e.g., lien payoff, lien placement or transfer,etc.); (3) Insurance (e.g., verification of insurance, insurancequoting, claim handling, total loss, etc.); (4) Automobile Manufacturers(e.g., VIN seeding, recall notices, technology upgrades, updatedsoftware versions, etc.); and/or (5) Salvage Vendors (e.g., titletransfer, exchange of monies, sensor or part valuation, vehicle orsensor auction, total loss, etc.).

In one embodiment, transactions associated with a total lossdetermination may be recorded on the Blockchain VIN Registry. Thetransactions may include the VIN, and data related to the followingevents or conditions: (1) a vehicle is involved in a crash with anothervehicle; (2) a blockchain may be used to determine active insurance andanother insurer; (3) determine if a lien is active, and if so, thepresent payoff amount, and identify the bank or other lender; (4) theinsurer may send the payoff amount and the bank may update the lienpayoff and remove the lien on vehicle; (5) title or e-title istransferred to an insurance company; (6) title or e-title is latertransferred to a salvage vendor; (7) the salvage vendor may sell thevehicle; and/or (8) after which, title or e-title is subsequentlytransferred to new owner, and/or the insurer receives salvage proceedsfrom vehicle being sold.

In another embodiment, transactions associated with vehicle manufactureand initial vehicle purchase/loan may be recorded on the Blockchain VINRegistry. The transactions may include the VIN, and vehicle or otherdata related to the following events or conditions: (1) a new vehicle ismanufactured, and VIN and associated information is added to theblockchain; (2) a consumer takes out a loan on the new (or another)vehicle, and a lien payoff amount is placed on the blockchain; (3) theconsumer receives title or e-title to the vehicle through the State DMV;(4) the bank places a lien on the vehicle title or e-title; and/or (5)auto insurance is purchased for the driver, vehicle, and/or autonomousvehicle.

In another embodiment, transactions associated with vehicle refinancingmay be recorded on the Blockchain VIN Registry. The transactions mayinclude the VIN, and vehicle or other data related to the followingevents or conditions: (1) a vehicle may be refinanced through anoriginal or subsequent bank, (2) the bank may query for a lien packet,(3) loan terms may be determined and updated, (4) payoff amounts may beupdated, etc.

Exemplary Virtual Claim Experience Using Blockchain

FIG. 4 depicts exemplary transactions that may be recorded, logged, orupdated in each block of a distributed ledger or Blockchain VIN Registry400. The transactions may each include a VIN for a particular vehicle,and one or more additional data elements. The additional data elementsmay include (i) identification a stakeholder or actor; (ii) tasks to beperformed or that have been completed; (iii) an output; and/or (iv)other data, including that discussed elsewhere herein.

The stakeholder or actor data elements may indicate or identify (1)vehicle owners, (2) repair facilities, (3) insurer, (4) part suppliers,(5) logistics providers, and/or (6) rental providers. Each stakeholderor actor data element may have a corresponding task assigned, or a taskbe, or has been, completed.

The task data elements for, and/or associated with, vehicle owners mayinclude (1) providing authorization to repair vehicle; (2) authorizingpayment to a repair facility; (3) paying a deductible; and/or (4)completing any necessary forms.

The task data elements for, and/or associated with, repair facilitiesmay include (1) taking possession of vehicle; (2) arranging forrental/substitute transportation; (3) securing authorization to repair;(4) identifying potential areas of prior damage/betterment; (5)developing a repair plan; (6) preparing an estimate; (7) sending alisting of necessary parts to suppliers; (8) finalizing parts order andordering parts; (9) uploading an estimate; (10) checking delivered partsversus parts ordered; (11) repairing the vehicle; (12) providing arepair status updates to the vehicle owner; (13) managing sublet repairtasks; (14) detailing and delivering the vehicle; (15) providing thevehicle owner with a repair warranty; and/or (16) sending a final repairbill to the insurer.

The task data elements for, and/or associated with, insurers may include(1) receiving a loss report; (2) determining coverage and policyconditions; (3) vehicle triage; (4) sending an assignment to the repairfacility; (5) authorizing a rental vehicle if applicable; (6) resolvingany prior damage/betterment issues; (7) sending an estimate and partsbrochures to the vehicle owner; (8) performing a vehicle inspection ifand when required; and/or (9) paying the final repair and any rentalbills.

The task data elements for, and/or associated with, parts suppliers mayinclude (1) receiving notification of a parts request; (2) competing fora parts sale; (3) packaging parts order for delivery; and/or (4) workingwith logistics provider to load parts.

The task data elements for, and/or associated with, logistics providersmay include (1) receiving parts delivery notification; (2) aggregating aparts order; (3) verifying part quality “grade” and/or checking for partdamage; and/or (4) delivering parts to repair facility.

The task data elements for, and/or associated with, rental providers mayinclude (1) providing replacement or rental vehicles; and/or (2) sendinga final rental bill.

The output data elements that may be associated with transactions, andidentified by VIN, and added to the Blockchain VIN Registry may furtherinclude signed repair authorizations and signed directions to pay(associated with the vehicle owner); printed final repair bills andprinted customer warranties (associated with the repair facility);printed or mailed repair estimates and printed or mailed alternativeparts brochures (associated with the insurer); archived parts orders(associated with the parts supplier); archived shipping orders(associated with the logistics provider); and final rental bills(associated with the rental provider). EXEMPLARY METHOD FOR INTERACTINGWITH A DISTRIBUTED LEDGER OF FINANCIAL TRANSACTIONS FOR A VEHICLE

FIG. 5 depicts an exemplary computer-implemented method 500 for creatingor interacting with a distributed ledger of transactions or eventspertaining to a particular vehicle. The method 500 depicted in FIG. 5may employ any of the distributed ledger/blockchain techniques, methods,and systems described above with respect to FIGS. 1-4.

During the course of a vehicle's lifetime multiple financial relatedevents may occur. These events may include, for example, an initialpurchase of the vehicle, subsequent purchases of the vehicle, financingextended to customers to purchase the vehicle, as well as other relatedevents. These events involve multiple parties such as financialinstitutions, insurance companies, government agencies, and individualconsumers. However, no single source of truth exists for financialinformation related to a particular vehicle. Individuals, ororganizations, that need to verify insurance exists covering thevehicle, or that the vehicle is free of any liens may need to consultmultiple databases that do not talk to each other. Accordingly, by usinga distributed ledger of financial events related to a particular vehiclethe individuals and organizations can easily find all of the relevantfinancial information for a vehicle. Using a distributed ledger, orblockchain, streamlines communication for all parties involved andproduces efficiency gains. Additionally, a single source of truthremoves any confusion as to whether the information presented about thevehicle is accurate, because the blockchain is updated and maintained bymultiple parties that are in turn validating the information submittedto the blockchain.

In one embodiment, a computer-implemented method for creating and/ormaintaining a VIN-based distributed ledger of financial transactions orevents pertaining to a particular vehicle may be provided. The methodmay include (1) receiving, by one or more processors and/ortransceivers, vehicle or financial data from one or more remotecomputing devices (e.g. user mobile devices, connected vehicles, vehiclesensors, vehicle manufacturer remote servers, bank remote servers,insurance provider remote servers, or repair facility remote servers),such as via wireless communication or data transmission over one or moreradio frequency links or digital communication channels (block 502); (2)detecting, by the one or more processors, a financial event for thevehicle from analysis of the vehicle or financial data (block 504); (3)identifying, by the one or more processors, the VIN of the vehicle orretrieving the VIN from a memory unit or the vehicle (or the vehicle'sprocessor or memory) when the financial event for the vehicle isdetected (block 506); (4) generating, by the one or more processors, atransaction or event (i) including the vehicle's VIN, (ii) describingthe financial event for the vehicle, and/or (iii) detailing a currentstatus, owner, and/or location of the vehicle (block 508); and/or (5)transmitting, from one or more processors and/or transceivers to aserver (such as via wireless communication or data transmission over oneor more radio frequency links), the transaction to facilitate creatingand/or maintaining a VIN-based distributed ledger detailing financialevents for the particular vehicle (block 510).

In some embodiments of the computer-implemented method, the financialevent detected is a new vehicle purchase, and the transaction or eventdescribes or details the new vehicle purchase, and/or a loan for thevehicle and a lender or bank. Similarly, in other embodiments, thefinancial event detected is a vehicle loan, and the transaction or eventdescribes or details the vehicle loan, a purchaser, and a lender orbank, a vehicle title and registration, or combinations thereof.Accordingly, in some embodiments the financial event may be acombination of the aforementioned related to a purchase of the vehicleusing financing.

In other embodiments, the financial event detected is a vehicle titletransfer, and the transaction or event describes or details the transferof vehicle title from one party to another. In other embodiments, thefinancial event detected is a vehicle loan, and the transaction or eventdescribes or details an insurance policy covering the vehicle. As such,in some embodiments, when the financial event detected is a vehicleloan, and the transaction or event describes or details one or moresmart contracts covering the vehicle.

In an alternative embodiment, a computer-implemented method formaintaining a VIN-based distributed ledger of financial transactions orevents pertaining to a particular vehicle may be provided. The methodmay include: (1) receiving, by one or more processors financial datafrom one or more remote computing devices; (2) detecting, by the one ormore processors, a financial event for the vehicle from analysis of thefinancial data; (3) identifying, by the one or more processors, the VINof the vehicle when the financial event for the vehicle is detected; (4)generating, by the one or more processors, a transaction (i) includingthe vehicle's VIN, (ii) describing the financial event for the vehicle,and (iii) detailing a current status, owner, and location of thevehicle; (5) updating, by the one or more processors, a smart contractassociated with the vehicle; and/or (6) transmitting, from one or moreprocessors to a server, the transaction to facilitate maintaining aVIN-based distributed ledger detailing financial events for theparticular vehicle.

In another embodiment, a computer system configured for creating and/ormaintaining a VIN-based distributed ledger of financial transactions orevents pertaining to a particular vehicle may be provided. The computersystem may include one or more processors, transceivers, sensors, and/orservers configured to: (1) receive vehicle or financial data from one ormore remote computing devices (e.g. user mobile devices, connectedvehicles, vehicle sensors, vehicle manufacturer remote servers, bankremote servers, insurance provider remote servers, or repair facilityremote servers), such as via wireless communication or data transmissionover one or more radio frequency links or digital communicationchannels; (2) detect a financial event for the vehicle from analysis ofthe vehicle or financial data; (3) identify the VIN of the vehicle orretrieving the VIN from a memory unit or the vehicle (or the vehicle'sprocessor or memory) when the financial event for the vehicle isdetected; (4) generate a transaction or event (i) including thevehicle's VIN, (ii) describing the financial event for the vehicle,and/or (iii) detailing a current status, owner, and/or location of thevehicle; and/or (5) transmit to a server (such as via wirelesscommunication or data transmission over one or more radio frequencylinks), the transaction or event to facilitate creating and/ormaintaining a VIN-based distributed ledger detailing financial eventsfor the particular vehicle.

ADDITIONAL CONSIDERATIONS

An authoritative, trusted, immutable, distributed, shareable, securesystem may be needed to record if a human driver is controlling avehicle, and/or if the vehicle is acting autonomously. The record mayinclude crash sensor data to record crash information correlating todriver control information.

Blockchain technology may be used to store the transactions of controlinstances (from autonomous to human control to autonomous, for example).These control instances may be stored as they occur into blocks.Accordingly, this data may be included into the distributed ledgerenvironment of the blockchain. In this environment, a consensus systemmay fix the events/blocks immutably and securely.

As noted herein, after collection of the information regarding thevehicle by one or more nodes within a communication network, atransaction (and/or new block) including the vehicle informationcollected may be broadcast to the blockchain, and/or a new blockverified and then added to the blockchain to reflect an updated state ofthe vehicle. For each of the computer-implemented methods discussedherein, in one embodiment, a transaction and/or new block may begenerated and then broadcast to the blockchain network for verificationonce vehicle data, and/or new sensor or other data, have been generatedand/or collected by one or more nodes within the communication network.As such, tracking the status of a vehicle may be more reliable and/orfraud-resistant as each node may include a proof-of-identity in itstransaction modifying the state of the vehicle and/or vehicle-relatedblocks or blockchain.

Further, with the computer-implemented methods discussed herein, networkparticipants may function as full nodes that validate and/or generatenew blocks and transactions, and/or compile transactions into blocksthat are then added to the network. However, not all participants needbe nodes that compile transactions into blocks, and/or validatetransactions and blocks received from other network participants—as somenetwork participants may wish to rely on other network nodes to providecomputer processing and/or storage services that enable usage of thesystem or blockchain.

In some scenarios, the blockchain may have public interfaces that allowvisibility into the data. In one embodiment, a private blockchaininterface may also be used by auto manufacturers, law enforcement,insurers, and regulatory agencies.

An element of smart contracts may also be enabled in the system.Depending on the sequence of events in the blockchain, terms of thesmart contract may be executed immediately, such as sending a tow truckto the geolocation if tow assistance is a part of the policy, filing alegal action by a subrogation team of an insurer is brought against anauto manufacturer (for example, if an accident occurs when theautonomous vehicle was in autonomous control), conducting a policyreview, filing a police report request with the jurisdiction of theroadway, processing claims awards made (for example, a partial paymentif deductible is met, to handle car rental or minor medical expense),sending a renewal notice for the policy, and so on.

In some aspects, customers may opt-in to a rewards, loyalty, or otherprogram. The customer may allow a remote server, such as an enforcementserver, to collect sensor, telematics, smart or autonomous vehicle,mobile device, and other types of data discussed herein. With customerpermission or affirmative consent, the data collected may be analyzed toprovide certain benefits to customers. For instance, insurance costsavings may be provided to lower risk or risk averse customers.Discounts, including cryptocurrency, may be awarded to accountsassociated with the customer. The other functionality discussed hereinmay also be provided to customers in return for them allowing collectionand analysis of the types of data discussed herein, as well asparticipating in the validation of the data discussed herein.

Although the text herein sets forth a detailed description of numerousdifferent embodiments, it should be understood that the legal scope ofthe invention is defined by the words of the claims set forth at the endof this patent. The detailed description is to be construed as exemplaryonly and does not describe every possible embodiment, as describingevery possible embodiment would be impractical, if not impossible. Onecould implement numerous alternate embodiments, using either currenttechnology or technology developed after the filing date of this patent,which would still fall within the scope of the claims.

It should also be understood that, unless a term is expressly defined inthis patent using the sentence “As used herein, the term ‘______’ ishereby defined to mean . . . ” or a similar sentence, there is no intentto limit the meaning of that term, either expressly or by implication,beyond its plain or ordinary meaning, and such term should not beinterpreted to be limited in scope based upon any statement made in anysection of this patent (other than the language of the claims). To theextent that any term recited in the claims at the end of this disclosureis referred to in this disclosure in a manner consistent with a singlemeaning, that is done for sake of clarity only so as to not confuse thereader, and it is not intended that such claim term be limited, byimplication or otherwise, to that single meaning.

Throughout this specification, plural instances may implementcomponents, operations, or structures described as a single instance.Although individual operations of one or more methods are illustratedand described as separate operations, one or more of the individualoperations may be performed concurrently, and nothing requires that theoperations be performed in the order illustrated. Structures andfunctionality presented as separate components in example configurationsmay be implemented as a combined structure or component. Similarly,structures and functionality presented as a single component may beimplemented as separate components. These and other variations,modifications, additions, and improvements fall within the scope of thesubject matter herein.

Additionally, certain embodiments are described herein as includinglogic or a number of routines, subroutines, applications, orinstructions. These may constitute either software (code embodied on anon-transitory, tangible machine-readable medium) or hardware. Inhardware, the routines, etc., are tangible units capable of performingcertain operations and may be configured or arranged in a certainmanner. In example embodiments, one or more computer systems (e.g., astandalone, client or server computer system) or one or more modules ofa computer system (e.g., a processor or a group of processors) may beconfigured by software (e.g., an application or application portion) asa module that operates to perform certain operations as describedherein.

In various embodiments, a module may be implemented mechanically orelectronically. Accordingly, the term “module” should be understood toencompass a tangible entity, be that an entity that is physicallyconstructed, permanently configured (e.g., hardwired), or temporarilyconfigured (e.g., programmed) to operate in a certain manner or toperform certain operations described herein. Considering embodiments inwhich modules are temporarily configured (e.g., programmed), each of themodules need not be configured or instantiated at any one instance intime. For example, where the modules comprise a general-purposeprocessor configured using software, the general-purpose processor maybe configured as respective different modules at different times.Software may accordingly configure a processor, for example, toconstitute a particular module at one instance of time and to constitutea different module at a different instance of time.

Modules can provide information to, and receive information from, othermodules. Accordingly, the described modules may be regarded as beingcommunicatively coupled. Where multiple of such modules existcontemporaneously, communications may be achieved through signaltransmission (e.g., over appropriate circuits and buses) that connectthe modules. In embodiments in which multiple modules are configured orinstantiated at different times, communications between such modules maybe achieved, for example, through the storage and retrieval ofinformation in memory structures to which the multiple modules haveaccess. For example, one module may perform an operation and store theoutput of that operation in a memory device to which it iscommunicatively coupled. A further module may then, at a later time,access the memory device to retrieve and process the stored output.Modules may also initiate communications with input or output devices,and can operate on a resource (e.g., a collection of information).

The various operations of example methods described herein may beperformed, at least partially, by one or more processors that aretemporarily configured (e.g., by software) or permanently configured toperform the relevant operations. Whether temporarily or permanentlyconfigured, such processors may constitute processor-implemented modulesthat operate to perform one or more operations or functions. The modulesreferred to herein may, in some example embodiments, compriseprocessor-implemented modules.

Similarly, the methods or routines described herein may be at leastpartially processor-implemented. For example, at least some of theoperations of a method may be performed by one or more processors orprocessor-implemented modules. The performance of certain of theoperations may be distributed among the one or more processors, not onlyresiding within a single machine, but deployed across a number ofmachines. In some example embodiments, the processor or processors maybe located in a single location (e.g., within a home environment, anoffice environment or as a server farm), while in other embodiments theprocessors may be distributed across a number of locations.

Unless specifically stated otherwise, discussions herein using wordssuch as “processing,” “computing,” “calculating,” “determining,”“presenting,” “displaying,” or the like may refer to actions orprocesses of a machine (e.g., a computer) that manipulates or transformsdata represented as physical (e.g., electronic, magnetic, or optical)quantities within one or more memories (e.g., volatile memory,non-volatile memory, or a combination thereof), registers, or othermachine components that receive, store, transmit, or displayinformation. Some embodiments may be described using the expression“coupled” and “connected” along with their derivatives. For example,some embodiments may be described using the term “coupled” to indicatethat two or more elements are in direct physical or electrical contact.The term “coupled,” however, may also mean that two or more elements arenot in direct contact with each other, but yet still co-operate orinteract with each other.

As used herein any reference to “one embodiment” or “an embodiment”means that a particular element, feature, structure, or characteristicdescribed in connection with the embodiment may be included in at leastone embodiment. The appearances of the phrase “in one embodiment” invarious places in the specification are not necessarily all referring tothe same embodiment. In addition, use of the “a” or “an” are employed todescribe elements and components of the embodiments herein. This is donemerely for convenience and to give a general sense of the description.This description, and the claims that follow, should be read to includeone or at least one and the singular also includes the plural unless itis obvious that it is meant otherwise.

As used herein, the terms “comprises,” “comprising,” “includes,”“including,” “has,” “having” or any other variation thereof, areintended to cover a non-exclusive inclusion. For example, a process,method, article, or apparatus that comprises a list of elements is notnecessarily limited to only those elements but may include otherelements not expressly listed or inherent to such process, method,article, or apparatus.

This detailed description is to be construed as exemplary only and doesnot describe every possible embodiment, as describing every possibleembodiment would be impractical, if not impossible. One could implementnumerous alternate embodiments, using either current technology ortechnology developed after the filing date of this application. Uponreading this disclosure, those of skill in the art will appreciate stilladditional alternative structural and functional designs for system anda method for assigning mobile device data to a vehicle through thedisclosed principles herein. Thus, while particular embodiments andapplications have been illustrated and described, it is to be understoodthat the disclosed embodiments are not limited to the preciseconstruction and components disclosed herein. Various modifications,changes and variations, which will be apparent to those, skilled in theart, may be made in the arrangement, operation and details of the methodand apparatus disclosed herein without departing from the spirit andscope defined in the appended claims.

The particular features, structures, or characteristics of any specificembodiment may be combined in any suitable manner and in any suitablecombination with one or more other embodiments, including the use ofselected features without corresponding use of other features. Inaddition, many modifications may be made to adapt a particularapplication, situation or material to the essential scope and spirit ofthe present invention. It is to be understood that other variations andmodifications of the embodiments of the present invention described andillustrated herein are possible in light of the teachings herein and areto be considered part of the spirit and scope of the present invention.

While the preferred embodiments of the invention have been described, itshould be understood that the invention is not so limited andmodifications may be made without departing from the invention. Thescope of the invention is defined by the appended claims, and alldevices that come within the meaning of the claims, either literally orby equivalence, are intended to be embraced therein. It is thereforeintended that the foregoing detailed description be regarded asillustrative rather than limiting, and that it be understood that it isthe following claims, including all equivalents, that are intended todefine the spirit and scope of this invention.

The patent claims at the end of this patent application are not intendedto be construed under 35 U.S.C. § 112(f) unless traditionalmeans-plus-function language is expressly recited, such as “means for”or “step for” language being explicitly recited in the claim(s).

1. A computer-implemented method for maintaining a VIN-based blockchainof financial transactions or events pertaining to a particular vehicle,wherein blocks of the blockchain use a VIN as an identifier, the methodcomprising: creating a blockchain for the vehicle that includes: anowner information and title status block including a name and address ofa new owner, and an indication that the vehicle is registered, a builddata block including a description of a vehicle build, a lienholder andlien amount information block including a description regarding avehicle lien or loan, and an insurance policy block including adescription regarding an insurance policy covering the vehicle and anidentification of the insurer, wherein the blockchain for the vehicle isaccessible using a VIN of the vehicle as a key; receiving, by one ormore processors of a computing device, financial data from one or moreremote computing devices; detecting, by the one or more processors, afinancial event for the vehicle from analysis of the financial data;identifying, by the one or more processors, the VIN of the vehicle whenthe financial event for the vehicle is detected; accessing, by the oneor more processors at a memory of the computing device, the blockchainusing the VIN of the vehicle as the key to identify blocks that use theVIN of the vehicle as an identifier; generating, by the one or moreprocessors, an update transaction (i) including the vehicle's VIN, (ii)describing the financial event for the vehicle, and (iii) detailing acurrent status, owner, and location of the vehicle; and transmitting,via an application programming interface (API) of a server, the updatetransaction, wherein the API causes the server to add the updatetransaction to at least one of the blocks that use the VIN as anidentifier.
 2. The computer-implemented method of claim 1, wherein thefinancial event detected is a new vehicle purchase, and the updatetransaction describes the new vehicle purchase, the loan for thevehicle, a lender, or combinations thereof.
 3. The computer-implementedmethod of claim 1, wherein the financial event detected is the vehicleloan, and the update transaction describes the vehicle loan, apurchaser, and a lender.
 4. The computer-implemented method of claim 1,wherein the financial event detected is the vehicle loan, and the updatetransaction describes the vehicle loan, a purchaser, a lender, and avehicle title and registration.
 5. The computer-implemented method ofclaim 1, wherein the financial event detected is a vehicle titletransfer, and the update transaction describes the transfer of vehicletitle from one party to another.
 6. The computer-implemented method ofclaim 1, wherein the financial event detected is the vehicle loan, andthe update transaction describes details the insurance policy coveringthe vehicle.
 7. The computer-implemented method of claim 1, wherein thefinancial event detected is the vehicle loan, and the update transactiondescribes one or more smart contracts covering the vehicle.
 8. Acomputer-implemented method for maintaining a VIN-based blockchain offinancial transactions or events pertaining to a particular vehicle,wherein blocks of the blockchain use a VIN as an identifier, the methodcomprising: creating a blockchain for the vehicle that includes: anowner information and title status block including a name and address ofa new owner, and an indication that the vehicle is registered, a builddata block including a description of a vehicle build, a lienholder andlien amount information block including a description regarding avehicle lien or loan, and an insurance policy block including adescription regarding an insurance policy covering the vehicle and anidentification of the insurer, wherein the blockchain for the vehicle isaccessible using a VIN of the vehicle as a key; receiving, by one ormore processors of a computing device, financial data from one or moreremote computing devices; detecting, by the one or more processors, afinancial event for the vehicle from analysis of the financial data;identifying, by the one or more processors, the VIN of the vehicle whenthe financial event for the vehicle is detected; accessing, by the oneor more processors at a memory of the computing device, the blockchainusing the VIN of the vehicle as the key to identify the blocks that usethe VIN of the vehicle as an identifier; generating, by the one or moreprocessors, an update transaction (i) including the vehicle's VIN, (ii)describing the financial event for the vehicle, and (iii) detailing acurrent status, owner, and location of the vehicle; updating, by the oneor more processors, a smart contract associated with the vehicle; andtransmitting via an application programming interface (API) of a server,the update transaction, wherein the API causes the server to add theupdate transaction to at least one of the blocks that use the VIN as anidentifier.
 9. The computer-implemented method of claim 8, wherein thefinancial event detected is a new vehicle purchase, and the updatetransaction describes the new vehicle purchase, the loan for thevehicle, a lender, or combinations thereof.
 10. The computer-implementedmethod of claim 8, wherein the financial event detected is the vehicleloan, and the update transaction describes the vehicle loan, apurchaser, and a lender.
 11. The computer-implemented method of claim 8,wherein the financial event detected is the vehicle loan, and the updatetransaction describes the vehicle loan, a purchaser, a lender, and avehicle title and registration.
 12. The computer-implemented method ofclaim 8, wherein the financial event detected is a vehicle titletransfer, and the update transaction describes the transfer of vehicletitle from one party to another.
 13. The computer-implemented method ofclaim 8, wherein the financial event detected is the vehicle loan, andthe update transaction describes details an insurance policy coveringthe vehicle.
 14. A computer system configured for maintaining aVIN-based blockchain of financial transactions pertaining to aparticular vehicle, wherein blocks of the blockchain use a VIN as anidentifier, and the computer system includes one or more processors,transceivers, sensors, or servers configured to: create a blockchain forthe vehicle that includes: an owner information and title status blockincluding a name and address of a new owner, and an indication that thevehicle is registered, a build data block including a description of avehicle build, a lienholder and lien amount information block includinga description regarding a vehicle lien or loan, and an insurance policyblock including a description regarding an insurance policy covering thevehicle and an identification of the insurer, wherein the blockchain forthe vehicle is accessible using a VIN of the vehicle as a key; receive,at the computer system, financial data from one or more remote computingdevices; detect a financial event for the vehicle from analysis of thefinancial data; identify the VIN of the vehicle when the financial eventfor the vehicle is detected; access, at a memory of the computer system,the blockchain using the VIN of the vehicle as the key to identifyblocks that use the VIN of the vehicle as an identifier; generate anupdate transaction (i) including the vehicle's VIN, (ii) describing thefinancial event for the vehicle, and (iii) detailing a current status,owner, and location of the vehicle; and transmit, via an applicationprogramming interface (API) of a server, the update transaction, whereinthe API causes the server to add the update transaction to at least oneof the blocks that use the VIN as an identifier.
 15. The computer systemof claim 14, wherein the financial event detected is a new vehiclepurchase, and the update transaction describes or details the newvehicle purchase, or the loan for the vehicle and a lender or bank. 16.The computer system of claim 14, wherein the financial event detected isthe vehicle loan, and the update transaction or event describes ordetails the vehicle loan, a purchaser, and a lender or bank.
 17. Thecomputer system of claim 14, wherein the financial event detected is thevehicle loan, and the update transaction or event describes or detailsthe vehicle loan, a purchaser, a lender or bank, and a vehicle title andregistration.
 18. The computer system of claim 14, wherein the financialevent detected is a vehicle title transfer, and the update transactionor event describes or details the transfer of vehicle title from oneparty to another.
 19. The computer system of claim 14, wherein thefinancial event detected is the vehicle loan, and the update transactionor event describes or details an insurance policy covering the vehicle.20. The computer system of claim 14, wherein the financial eventdetected is the vehicle loan, and the update transaction or eventdescribes or details one or more smart contracts covering the vehicle.